Both options operate on the transaction event that span streaming no longer
produces, so they silently stopped taking effect when span streaming became
the default. That is easy to miss when upgrading.

Deprecate both options with a note that they only apply in combination with
`traceLifecycle: 'static'` and will be removed in v12, and warn at init time
when either is set while span streaming is enabled. The warning writes to the
console directly rather than through `debug`, which is opt-in and stripped from
non-debug bundles, so users who need to see it actually do.

The check runs after integration setup because `spanStreamingIntegration` can
fall back to the static trace lifecycle, in which case both options do apply
and we must stay silent.

Fixes #22856
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The warning ships in every bundle, including the base CDN bundle that has no
tracing at all, so its message text is paid for by users who will never see it.

Measured against a build with the feature stubbed out, the original cost 204 B
gzipped in the base CDN bundle. Almost all of that was the message: dropping the
array/filter/join in favour of a single static string, and giving up naming
which of the two options is actually set, brings it to 87 B — a 117 B saving.

Naming the specific option was the expensive part, not the machinery that
selected it; an interpolation-free ternary variant measured worse than the array
it would have replaced. The static message still names both options, both
replacements, and the opt-out, so it loses no actionable information.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

A disabled client (no DSN, or `enabled: false`) skips `_setupIntegrations()`,
so `spanStreamingIntegration` never gets the chance to fall back to
`traceLifecycle: 'static'`. The lifecycle stayed 'stream' and the warning fired,
telling users their options were ignored because of span streaming — when the
real reason was that the client sends nothing at all.

The two paths were verifiably indistinguishable to the user: with an unwrapped
`beforeSendSpan`, the identical config warns without a DSN and stays correctly
silent with one, purely because setup ran in the second case.

Move the call inside the branch that sets integrations up. The Spotlight escape
hatch is handled correctly by construction: a DSN-less client with Spotlight
does set up integrations and does send spans, so it should still warn.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>